NW X Security JAWS勉強会#3レポート #nwsecjaws3 #jawsug

こんにちは、臼田です。

伝説のNW-JAWSとSecurity-JAWSのコラボ勉強会が満を持して3回目の開催をしましたのでレポートします。

NW X Security JAWS勉強会#3 - connpass

動画

レポート

L1-2: データセンターインフラ：エンジニアリングとオペレーションの現場 アマゾンデータサービスジャパン合同会社 Data Center Enginereing Operation 中台拓也 さん

• AWSではなくADSの所属
  • ADSはデータセンターを運営している
  • ファシリティマネージャーをしている
  • 普段はAWSを使っている人たちと接する機会は多くない
  • 絶対に止めてはいけないから熱意を持って運営している
  • データセンターファシリティに関わって約13年目
• AWSの日本に対する投資のニュースも出ているが、需要が高まってきている
• データセンターを運用するための要素
  • シンガポールは国土が狭く、電力が足りなかった
  • 用地できず大規模に作れなかった
  • 国の電力供給量を増やさないといけない
  • 作りたくても作れないという事象もある
  • 日本でももしかしたらこのような問題が起きる可能性もある
• データセンターの構築
  • 作る前に考慮すること
  • Availability Zone
    • データセンターの物理的な距離は大事
  • 需要に答える供給スペースを確保する必要がある
    • スペースが見つかっても作りたい形にハマるかも大事
  • 地理的災害リスク
    • 地震はもちろん活断層が通っているか
    • 洪水リスク
  • 近隣リスク
    • 飛行機や鉄道、軍の設備が近くにあるか
    • 攻撃を受けて巻き込まれる可能性
    • これらも物理的な脅威のリスク
  • 電力
    • 電力線1本で使うことはない
    • 電力会社のメンテナンスによる停電リスクなど
    • 変電所の供給量がマッチしているか
  • ネットワークの接続性
    • ファイバーの冗長が可能か
    • 敷地への入線経路
    • ビルの縦管
    • 誤った掘削がされないか
    • 都内の中心以外はファイバーが埋設されていないため、冗長化が大変
  • 運用の人材が確保できるか
    • 昔は市場規模が小さかった
    • 最近は需要が増えてきている
    • ハイセキュリティなため経験のある人材の確保が難しい
    • ここが関東圏に作られる理由になっている
• データセンターエンジニアリング
  • 複雑性と影響範囲
    • これをなるべく少なくする
    • たとえば昔はUPSで2MWの大容量のものを使っていた
      • 特定の会社が作っていた
      • このUPSのシステムに不具合があったとき多くのサーバーラックに影響を与える
      • 15kWのUPSをサーバーラックの中に搭載するように変わっていった
      • ユニットとして使う
      • なるべく中央のUPSを使わないようにする
      • UPSを自社開発して対応に時間がかかるリスクを減らした
      • 故障範囲も小さくできてお客様影響を減らせる
    • AMCOP: バックアップ電源切替制御
      • 電源のパネルの制御をしていた
      • これもサードパーティに依存すると対応が遅くなるので自社開発した
    • DLB: 冗長電源の切替制御(ロードバランス)
    • BACOP: 電源容量超過時の遮断制御
    • 一通り自社で開発している
    • 基本は自動でコントロールしている
    • コントロールされる側とのコミュニケーションは大切
    • データセンター施工時に認識連れをなくす
• データセンターの運用
  • Live Load Transfer Test
    • 実負荷をプライマリー電源(商用電源)からバックアップ電源に切り替えるテスト
    • 計画的に模擬しているのですぐに戻せる、実際の停電を模擬することで信頼性を確保する
  • 空調制御テスト
    • 空調はサーバーの熱を処理してエアーを送り込む
    • 制御用のコントローラーがある
    • コントローラーも定朝していてこれもテストしていく
    • 電気なら切り替えだけだが空調は送風機や熱交換器など複数のコンポーネントを制御する必要がある
    • それぞれのコンポーネントのコントローラー1つ1つ障害注入していく
  • 緊急対応ドリル
    • フルオートメートで切り替わるとしても現地で緊急対応が必要なことはある
    • すぐに対応できるように手順書が用意されている
    • しかし手順書は机上の空論になりがち
    • 実際に自分たちで現地で操作する
      • バルブの操作をしてくださいという手順で、バルブが5mの高さにあるとか、やらないと気づかないことはある
      • 毎週やっている
      • 次の週に手順をブラッシュアップしてもう一回やっている
• ぜひ安心して使ってほしい

感想

いやーすごいですね。そして、システムの可用性の話と通ずるところがたくさんありますね。まさにカオスエンジニアリングしたりしていますね。安心して使っていきましょう。

L3-4: AWS環境IPv6移行に向けて知っておきたいこと NTT東日本 白鳥翔太 さん

資料と解説はこちら

• 話すこと
  • IPv6 on AWS
  • 基本的な話はしない
• IPv6の背景の話からしていく
  • パブリックIPv4が有料化された
  • これまではEIPのみ課金だったが自動払い出しのIPv4も課金対象になった
  • できるだけIPv4を減らしていきたい
  • そもそもグローバルIPv4アドレス自体枯渇している
  • 国内のIPv6トラフィックも50%を超えてきている
• AWSエンジニアのためのIPv6基礎
  • IPv6アドレスの表記方法
    • 128bitを16bitずつ8つにコロンで区切って16進数表記
    • アドレス帯の0が続く場所は省略できる
    • ループバックアドレスやマルチキャストアドレスなど特殊なアドレス帯もある
  • IPv6プレフィックス
    • JPNICからは/48か/56で払い出す
    • /64までサブネット識別子として使われるのが一般的
    • /56で払い出されたら2^8(256個)のサブネットを使うことになる
• AWSの各サービスのIPv6対応状況
  • 36サービスが対応している
  • しかし対応のパターンが4つある
  • デュアルスタックのリソース作成可能
  • IPv6のみリソース作成可能
  • パブリックIPv6エンドポイント
  • プライベートIPv6エンドポイント
  • ハマりポイント
    • SSMエンドポイントはIPv4のみ
    • NAT64とDNS64が必要になる
• IPv6のここ1年のアップデート
  • 12個あった
  • CIDRの調整ができるようになった
    • もともとは/56だけだったが/44 - /60まで選べるようになった
  • Global Acceleratorの拡張
  • IPv6ネイティブでオートスケールできるようになった
  • Network FirewallがIPv6のみに対応
  • 所管としてはデュアルスタックなら問題ないくらいになってきた
• IPv6 VPCを作ったときの基本的な仕様
  • IPv6アドレッシング
    • VPC自体はIPv4を無効化できない
    • IPv6サブネットは作れる
    • IPv4とIPv6は独立して通信
  • VPCでサポートされるサービス類
    • DHCPv6はff02::1:2
    • EC2の命名規則が変わる
      • インスタンスIDが入る
  • VPCのコネクティビティ
    • VPCピアリングは普通に使える
    • Transit Gatewayはデュアルスタックサブネットに作る
    • Cloud WANも使える
    • Private Linkはどちらもつかえる
    • VPCシェアリングはデュアルスタックサブネットで利用可能だがIPv6は非共有サブネットになる
  • 外部からのアクセス
    • 外からアクセスさせたくないならEgress Only Gatewayを使う
    • DXはBGPおｍIPv6可能
    • S2S VPNはTGWで終端するもののみ
    • TGW ConnectはサポートしているがMP-BGP必要
  • セキュリティと運用
    • SG/NACL/フローログ使える
    • トラフィックミラーリングのターゲットはv4のみ
    • WAFはIPv4と同様
    • Network Firewallはネイティブ対応
    • SSMはIPv4のみ、デュアルスタック自体は可能
  • 可用性
    • ELB使用可能だがTGで混在はできない
    • Global Accelerator使える
    • CloudFrontエッジまではIPv6対応、オリジンはIPv4のみ
• AWS環境のIPv6移行
  • 既存環境の移行
    • IPv4のみのサブネットをデュアルスタックに移行は可能
    • IPv6のみにするなら新しいサブネットを作って移行する必要がある
    • 移行手順
  • IPv6ネイティブが向く環境
    • EC2のみのモノリシック環境
    • EC2ベースの分散環境
  • デュアルスタックが向く環境
    • Web三層
    • GAを使う
  • IPv4のみが向く環境
    • CloudFrontを使う
    • 閉域接続・オンプレミスとハイブリッド構成(そもそもオンプレのIPv6が難しい)
• リファレンスアーキテクチャ
  • スライドみてね☆ミ
• まとめ
  • IPv4は限りある資源なのでサステナビリティに貢献しよう
  • 最近のアップデートでデュアルスタックならだいたいできるようになってきた

感想

IPv6対応、コスト的にはやっていきたいですが、気にすることはたくさんありますね。よくチェックしてサステナビリティに貢献していきましょう！

L5-7: TLS1.3対応のサービスが増えているが、クライアントアプリケーション側で考慮すべきことも考えてみる クラスメソッド株式会社 岩浅貴大（いわさ） さん

資料と解説はこちら

• 札幌からリモートでの参加
• 得意なのはアプリケーション
• 今日は話さないこと
  • 0-RTTやQUICは話さない
• 話すこと
  • バージョン・互換性などもっと単純なところの話
  • TLSに関する特にバージョン周りについてサーバーとクライアントの関係を知っておく
• 最近TLS1.3対応のAWSサービスが増えている
• みんなSSL/TLS使ってるよね？
• IPAのTLS暗号設定ガイドラインがわかりやすい
• 多くの人が使っているはずなTLS
  • HTTPで使うことが多いがSMTPやFTPなどでも使われている
  • レガシーバージョンどこまで使うのかとか気にすることが多いのでは
• はじめに
  • バージョン周り
  • TLSのバージョンどうする？
    • サーバーサイド
      • どのバージョン？どのスイート？
      • AWSだとセキュリティポリシーを何にしているか
    • クライアントサイド
      • ライブラリによってはTLSバージョンを指定するオプションがあるか
      • どのバージョンで接続しに行こうとしているか
• TLS1.3対応のAWSサービス
  • そもそもTLS1.3とは
    • 1999年からTLS1.0
    • 現在ではTLS1.2からのみ利用推奨
    • ほかは非推奨や廃止
  • TLS1.3は何が変わったのか
    • つまりよりセキュアでよりパフォーマンスが良い
  • 本日時点でTLS1.2は非推奨ではない
    • TLS1.3のみに移行する必要はないと言われている
    • ただしTLS1.2の中で推奨事項がある
  • AWSの話
    • CloudFrontやNLBは早い段階でTLS1.3対応していた
    • 最近はいろんなサービスが対応し始めてきた
    • ロードバランサーなどでセキュリティポリシーの設定がある
      • ポリシーでリストから選ぶ方式
      • ポリシーごとにサポートするプロトコルと暗号スイートが決まっている
      • レガシークライアントのサポートにこだわりがなければ推奨されるものを使えばいい
      • ALB/NLBではTLS1.3のみがあるが、対応していないクライアントが接続できなくなる
    • AWSサービスごとTLSの設定が違う
    • 詳細は下記ブログをみてください

• • • TLS1.3をあえて使わないという選択肢はない
    • クライアントが対応していれば勝手にTLS1.3になっている
  • AWSのまとめ
    • TLS1.3サポートが増えている
    • 勝手に適用されている
    • 限定されたポリシーもあるので使うなら注意
• クライアントサイドの話
  • AWSサービス側でTLS1.3が勝手に使われているけど大丈夫？
    • TLS1.3は以前のバージョンと直接の互換性はありません
    • ほとんどの場合はブラウザで勝手にサポートされ透過的に利用できるはず
  • バージョンネゴシエーション
    • TLS始める前にネゴシエーションする
    • クライアント側はブラウザやライブラリで違いはあるがプロトコルと暗号スイートのリストを持っている
    • Client helloで対応しているものを送る
    • サーバーはサーバーで使えるものを選択して返す
    • マッチしなければClose notifyで止める
    • ネゴシエーションはcurlだと-vでみれる
    • 詳細に見るならWiresharkでみれる
    • サポートしているプロトコルと暗号スイートが確認できる
  • クライアントがサポートするTLSバージョンを把握したい
    • Webのフロントエンドはブラウザバージョンに依存
    • モバイルアプリはOSバージョンに依存
      • 独自実装している場合もある
    • その他のクライアント
      • クライアントでバラバラ
      • HTTPクライアントやライブラリで独自にやっている場合もある
  • TLS1.3が使えないクライアント
    • まれにいる
    • 古いOS、古いブラウザバージョンはだめ
    • これをレガシークライアントと呼ぶ
    • クロスプラットフォーム環境などでTLSバージョンを指定する独自実装しているときにハマるかも
    • クライアントごと対応状況を実際に確認すると言い
    • サードパーティの検証サイトもある
• まとめ
  • セキュリティポリシーをTLS1.3のみにする場合は注意
  • TLS1.2=セキュアとは限らない
  • クライアントの実装気をつけよう
    • クライアントはブラウザやOSなどプラットフォームに任せるといい

感想

レガシークライアント、なんとかしましょうね

L7+: 生成AIのセキュリティについて学ぼう JBアドバンスト・テクノロジー株式会社 新居田晃史 さん

• ちょっと人よりフルマラソンを走るのが早い
• 普段はJAWS-UG横浜支部などで活動している
• 生成AIとは
  • いままで機械学習やDLなどでAIを使っていくのは大変だった
  • APIからSDKから簡単にいいものを使えるようになった
  • いい時代が来た
  • しかしブラックボックスも多いので注意する必要がある
• キーワードは信頼性の担保
• 生成AIの利用におけるリスク
  • 機密データの流出
    • ChatGPTなど打ち込んだら学習に使われるものがある
    • ChatGPTなら再学習する->設定でオフにできる
    • GitHub Copilot
      • ビジネスプランでは再学習しない
      • 個人プランでは再学習する->設定でオフにできる
    • Notion
      • ユーザーデータを学習しない
      • アクセス権を考慮
    • サービスの規約を見よう
    • お金を払おうね
  • 通常権限のないユーザーへの機密データの流出
    • 開発者寄りの話
    • RAGを構成した場合
      • アプリケーションから検索用のデータをDBから引いてくる
    • 検索用DBに見えちゃいけないデータがある場合、気をつける必要がある
  • 生成されたコードの安全性
    • 脆弱性のあるコード
    • 脆弱性のあるライブラリ
    • 使用することで許諾違反となるコード
      • 学習元がOSSで規約に違反するリスクがある
      • 判断は難しい
    • CIの中でチェックしたりしていく
• 生成AIを扱うためのガイドラインが必要
  • 日本ディープラーニング協会「生成AIの利用ガイドライン」
  • 開発におけるリスクはOWASP Top 10 for LLMを参考に
    • AWSでもドキュメントを出している
    • アプリケーションの多層防御セキュリティ設計が参考になる
    • ただし自然入力をどう対処していくかは難しい
    • 回答もブレるという特性が難しい
    • 信頼性を担保しにくい
      • プロンプトエンジニアリングしてブレにくくしていく
    • お金のかかるモデルならDoSで破産する可能性もある
    • AWSでもやっていくことは変わらない
• BedRockのセキュリティ
  • ユーザーガイドによくまとまっている
  • BedRockはプロンプトをAWSのモデルのトレーニングに使用したりサードパーティへの配布を行いません
  • コンプライアンスの項目があることでビジネスユースに有効
• 生成AIの攻撃手法(敵対的プロンプト)の例
  • プロンプトインジェクション
    • 行動を変更するプロンプトを使用してモデルの出力を乗っ取る
  • プロンプトリーク
    • 公開を意図していなかった機密情報を含むプロンプトから詳細を漏らす
  • ジェイルブレイク
  • 防御策
    • 最近のモデルはだいたい対策されている
      • ただ、実際に試さないとね
    • 入力値と応答は取っておかないと辿れない
• Guardrails for Amazon Bedrock
  • 2024/04/24にGAした！
  • 望ましくないトピックをブロック
  • 有害なコンテンツをフィルタリング
  • 機密情報(PII)を編集
  • 不適切なコンテンツをブロック
• まとめ
  • 何を守りたいかを定義し、ガイドラインを制定しよう
  • 生成AIは不安定なもの「推測するな、計測せよ」
  • まずやってみよう

感想

乗るしかない、このビッグウェーブに！Guardrailを活用して便利に使っていきたいですね。

L0: フィジカルセキュリティ – Corporate Securityの在り方 アマゾンジャパン合同会社 Amazon Corporate Security (ACS) フルーティー(Flouty) 憲子

• フィジカルセキュリティの領域の仕事をしている
• 仕事をする前の警備のイメージ
  • 警備の制服を着ているおじさんのイメージ
• フィジカルセキュリティのステータス向上の活動などをしている
• ステータス向上の前には警備の人に対して、「立っているだけならちょっと荷物を運ぶのを手伝って」と言われることもあった
• カスタマーは従業員になる
• 従業員のより良い安心安全な職場の維持が仕事
• フィジカルセキュリティはただ立っているだけに見えるかもしれない
  • グローバルのチームと連携してリスクに対応している
  • 実際に現場で様々な物事に対応している
  • 小さいところなら冷蔵庫のプリンがなくなったというものにも対応
  • 人について侵入した場合にチェックしたり
• リクルート
  • 日勤のみ、夜勤のみ、どっちもいけるなど
  • しかしすべての業務を覚えてもらう
  • サポートに入れるようにする
  • トレーニングしたり、成果を確認してフィードバックするなどの業務もある
• Woman in Security
  • セキュリティ業界、特にフィジカルセキュリティ業界では女性が少ない
  • 女性のマネージャーなどにスポットライトを当てて話してもらうイベントがあった
  • 日本でも女性のセキュリティ関係のマネージャーは少ないけどわりといる

感想

フィジカルセキュリティも大事ですなあ。感謝して生きていきます。

さいごに

今回もてんこ盛りの内容で、とっても楽しかったです。

記事だけ見ている人はあとからアーカイブ動画を見てください！

すべてのセキュリティに感謝を。